1. Field of the Invention
The present invention generally relates to telecommunications networking technology. More particularly, the present invention relates to a scalable network device, such as a switch or a multiplexer (e.g., DSLAM, ATM switch).
2. Description of Related Art
At its most fundamental level, a telecommunications system should provide service between at least two end users with a minimum level of quality that is acceptable for the kind of traffic that is being transmitted between these end users. End users have different needs from the telecommunications system because of the types and volume of traffic between them. One end user could telephone another user for voice communication. Another end user could use a computer and a modem to send an email to another user for data communication. Additionally, another end user could use a computer and a modem to access any number of Web pages on the Internet. Depending on the type of data (e.g., text, graphics, audio, video) that is being accessed, bandwidth requirements will vary. Thus, one end user may have very basic needs with minimal bandwidth and lots of delays, while another end user may have stringent requirements for lots of bandwidth with minimal delays. How can a telecommunications system, and its components, be designed to accommodate the various uses and needs?
Currently, the telecommunications infrastructure comprises network nodes (e.g., ATM switches, routers, other central office switches) that are coupled together. At the edge of this infrastructure are edge nodes (e.g., DSLAMs) for providing telecommunications service to subscribers (e.g., home users, business users, ISPs) via some local loop technology (e.g., ISDN, DSL). As known to those skilled in the art, local loop (or loop) refers to the interface (typically wires) between the subscriber and the telephone company""s central office. Some of these network and edge nodes can be combined to create corporate networks and Intranets. These pieces of node equipment are usually installed and located in central offices as well as corporate offices. Communication between or among subscribers is possible through these network and edge nodes which run various communication protocols.
Although the bandwidth on the telecommunications backbone (e.g., DS3, OC3, STS3, or OC12) may be sufficient for all of the various types of traffic generated by subscribers, the bandwidth on the loop side is limited for today""s traffic needs. Historically, analog dial-up with analog signaling was more than sufficient for most traffic. Even the digitization of voice, which requires approximately 4,000 Hz bandwidth, posed no problem since the telephone companies provided 64 Kbits/sec of bandwidth per channel. However, with the rise of the Internet and the increased interest in digital video and audio services, earlier modems were sorely lacking as speeds were as low as 1,200 bits/sec (V.22) to 33.6 Kbits/sec (V.34+) to today""s 56 Kbits/sec (U.S. Robotics/3COM and Lucent/Rockwell). Even at 56 Kbits/sec, these modems are still too slow to fully capture digital audio and video services to the end user""s satisfaction. Even if modems could use all of the available 64 Kbits/sec bandwidth provided by the telephone company, users would still be dissatisfied for the latest audio and video digital services. To give the appearance that more traffic was being passed through the lines than was actually being transmitted, several companies developed and implemented compression techniques.
For some time, even before the onset of the Internet, several loop technologies were slowly developed for this markef. One such loop technology is ISDN (at 128 Kbits/sec), which failed to deliver on its promise of better digital service because of the high cost of ISDN equipment and the higher cost of upgrading central office hardware and software. Furthermore, ISDN equipment was difficult to set up and make compatible with existing equipment because of poor diagnostics. The rates set by the public utilities commissions of various states are also very high. As of this writing, however, ISDN still has not disappeared and some service providers are offering ISDN service.
The traditional forms of leased line technologies, including T1 (at 24 channels of 64 Kbits/sec each for a total bandwidth of 1.544 Mbits/sec), fractional T1 (where users can get as many T1 channels as desired), and T3 (at 44.736 Mbits/sec or 28 T1 circuits), were also, of course, available. However, their prohibitively high expense makes these line technologies less attractive to the average subscriber. Recently, the pace of loop technology development has picked up due to the rise and proliferation of Digital Subscriber Line (DSL). Other competing technologies include Cable (CATV) Data Networks and Modems (or cable modems) and fiber optics.
At this point, however, DSL appears to be the front runner for the broadest application across the telephone companies"" residential and small business subscriber base. However, DSL may not eliminate other technologies (e.g., T1, T3, ISDN, and cable modem) as the various telephone companies will make these technologies available to those who want them and can afford them. Various DSL technologies are available and they differ in technical operation rather than application. However, ADSL is receiving the most attention for loop technology in general and Internet access in particular. The entire XDSL family is provided below in TABLE A:
The first column, xe2x80x9cName,xe2x80x9d identifies the type of xDSL technology. Refer to the GLOSSARY to obtain the full name from the acronym. The second column, xe2x80x9cData Rate,xe2x80x9d is the typical maximum rate at which data transfers are accomplished for the various modes (see third column, xe2x80x9cModexe2x80x9d) for each xDSL type. While ADSL, RADSL, CDSL, and VDSL are non-symmetric (the downlink CO-to-subscriber rate is usually faster than the uplink subscriber-to-CO rate), HDSL, HDSL2, SDSL, and ISDL are syrnmetric. The fourth column, xe2x80x9cPhysical,xe2x80x9d provides a brief description of the distinctive physical layer requirements or properties for each of the xDSL types.
To make DSL work at a central office, a DSL access multiplexer (DSLAM) is needed. However, current DSLAMs are limited. Although the various types of DSL technologies will be implemented, most existing DSLAMs cannot support multiple DSL technologies; that is, a given DSLAM can only support one DSL technology. This limits what the telecommunications providers are willing to do to expand DSL throughout their respective network. Given the shortage of space in central offices today, telecommunications service providers may be unwilling to purchase multiple DSLAMs for all the different types of DSLs that are available. In other cases, these telecommunications service providers may only deploy certain DSL types to be supported by the limited DSLAMs.
Compounding the problem of existing DSLAMs being tied to a particular DSL type is the fact that some existing DSLAMs are also tied to a particular modem modulation technique, either CAP or DMT. A DSLAM that is compatible with both modulation techniques would be desirable.
Another problem with existing DSLAMs is the nature of the virtual connections supported. In order for any two subscribers to communicate, a virtual connection must be set up between them. The end users and the network nodes predefine and maintain a virtual circuit and virtual path through the packet-switched mesh-type network that the end users believe to be a dedicated physically connected circuit. The actual path, however, may change due to routing around down or busy connections through the ATM/router maze-like network. Regardless of the path, the packets are transferred, in order, over a specific path and arrive at the destination in order. Two types of virtual connections are knownxe2x80x94permanent virtual connection (PVC) and switched virtual connection (SVC). Existing DSLAMs do not support SVC because SVCs require signaling logic in the switches and end systems. Existing DSL modems, which are typically located at the end users"" locations, do not support SVC signaling.
A permanent virtual connection, or PVC, is a fixed circuit that is defined in advance by a public carrier or a network manager. Thus, all data traffic between two end systems that signed up for a PVC follows a predetermined physical path that makes up the virtual circuit. PVCs have traditionally been tailored for subscription-based services and are typically maintained for a long period of time. A PVC is permanently programmed into a network for continuous use (or as long as the subscriber desires) between end users for multiple sessions. Typical applications include multiple geographically disparate LANs tied together via a PVC to create a WAN so that data traffic can be supported between users of the two LANS.
The fixed nature of the PVC circuit removes setup and disconnect overhead but takes time to initially establish because each end user and node along the path have to be configured with all the PVC parameters by the network management system (e.g., carrier), which may also involve human intervention. Typically, however, the network administrator uses a console which provides a topology of the network and the network administrator has to set the proper routing parameters node by node. This is a tedious and time-consuming process.
The physical and permanent nature of PVCs is a major drawback. If any physical transmission line among the network nodes along the preprogrammed PVC path fails (e.g., the line is physically cut), this PVC-based telecommunications service between the calling parties may not be remedied in a timely fashion.
In contrast, a switched virtual connection, or SVC, is a temporary virtual circuit that lasts as long as the session between end users lasts. If a carrier supports SVCs, it can set up and disconnect SVCs on the fly using SVC signaling. Once the communication for a particular session is complete, the virtual circuit is disconnected. Thus, alternate paths can be set up among sessions between the same two communicating end users.
While PVC is statically set up and torn down by the network management system (e.g., carrier) in a very inefficient and untimely manner, SVCs are set up and torn down dynamically by the SVC signaling equipment at the ATM end users"" locations using a UNI signaling protocol. Thus, the SVC parameters are provided to the switches along the path for automatic configuration by the signaling protocols in a distributed fashion. However, as stated above, current DSLAMs do not support SVC signaling primarily because the loop side of the DSLAM is PVC-based. To provide flexibility to the telecommunications service providers, a DSLAM that supports SVC signaling even though the loop side is PVC based is needed. In effect, despite the lack of SVC signaling from the loop side, a DSLAM that can provide xe2x80x9cproxyxe2x80x9d signaling, i.e., logic in the DSLAM that provides signaling to other network nodes to give the appearance that SVC signaling came from the loop side, is desirable.
Another problem with existing DSLAMs is that they do not support Quality of Service. When a subscriber signs up for some telephone service at a particular Quality of Service, the telecommunications service provider physically sets up the connection. As known to those skilled in the art, Quality of Service (QoS) is a measure of the telephone service quality provided to a subscriber. With respect to ATM, QoS refers to the bundle of parameters that are associated with, at the very least, bandwidth, timing, and cell error/loss. In particular, the ATM Forum defined certain parameters in its UNI ATM Performance Parameters including bandwidth, cell error ratio, cell block ratio, cell loss ratio, cell transfer delay, mean cell transfer delay, and cell delay variability.
Another problem with existing node equipment is their undesirable blocking effect. As known to those skilled in the art, xe2x80x9cblockingxe2x80x9d and xe2x80x9cnon-blockingxe2x80x9d have many definitions. The typical usage of the term xe2x80x9cnon-blockingxe2x80x9d refers to the situation that when data at a particular bandwidth comes in to one of the input ports of the node, the output ports of the node should provide that data at the same bandwidth. In other words, the node should not block that data. Simply stated, blocking means that a call cannot be completed. Blocking usually occurs when the switching or transmission capacity is not available at that time. The blocking phenomenon typically arises because a telecommunications service provider oversubscribed its services; that is, the total number of subscribers supported by the switching equipment cannot have their full share of bandwidth and services during times of peak usage.
Understandably, no telecommunication service provider designs.its system for complete non-blocking capability. This would be too expensive as more and more sophisticated equipment and circuits are needed to provide more and more bandwidth for the given number of subscribers. The telecommunications service provider makes a trade-off decisionxe2x80x94what is the provider (and its subscribers) prepared to pay versus what is the provider (and its subscribers) prepared to tolerate in terms of blocked calls or data? More and more telecommunications service providers are willing to make this decision in favor of higher cost to assure its subscribers a higher grade of service. Because oversubscription is a common practice in the industry, most DSLAMs provide blocking, thus eliminating all the bandwidth gains achieved while the data makes its way to these DSLAMs.
Despite these problems associated with blocking and oversubscription, most industry efforts have not been focused on prioritizing the incoming data into service requirements. As mentioned earlier, the various data received by a DSLAM may have specific service requirements (e.g., bandwidth, time synchronization) which may be affected by the blocking phenomenon. To overcome this problem, Quality of Service (QoS) could be implemented to xe2x80x9cfairlyxe2x80x9d prioritize the various data received by the DSLAM so that some data can be serviced before other data, while at the same time, ensuring that all the data received are somehow xe2x80x9cfairlyxe2x80x9d serviced. As known to those skilled in the art, an unexploited feature of ATM is the the ATM Forum""s ATM service categories.
Five different service categories have been defined, including Constant Bit Rate (CBR), Real-Time Variable Bit Rate (rt-VBR), Non-Real-Time Variable Bit Rate (nrt-VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR).
CBR refers to Constant Bit Rate and it is used primarily for those types of data where end systems expect some time synchronization. CBR data requires some predictable response time and a static amount of bandwidth continuously available for the lifetime of the connection. The peak cell rate determines the bandwidth. Typical applications include video conferencing, voice telephony services, and on-demand services.
VBR refers to Variable Bit Rate. It can be either real-time (i.e., rt-VBR) or non-real-time (i.e., nrt-VBR). Real-time VBR is used for connections that transport variable bit rate traffic that relies on time synchronization between end systems. Real-time VBR is dependent on peak cell rate, sustained cell rate, and maximum burst size. Typical applications that use rt-VBR are variable rate compressed video.
Non-real-time VBR is used for connections that transport variable bit rate traffic that does not rely on time synchronization between end systems. However, nrt-VBR requires some guaranteed bandwidth or latency. Typical applications include frame relay interworking. A vast majority of current DSLAMs also do not support extensive Quality of Service (QoS). Accordingly, telecommunications service providers cannot build end-to-end ATM networks over DSL from the subscriber""s premises through a carrier ATM backbone network.
ABR refers to Available Bit Rate which is used for connections that transport variable bit rate traffic for which end systems do not expect time synchronization. Beyond a minimum cell rate, the end systems also do not require guarantees of bandwidth or latency. In effect, ABR is generally designed for those traffic that are not time sensitive and expects no service guarantees (beyond minimum cell rate). Flow control mechanisms are used to dynamically adjust the amount of bandwidth available to the user. The peak cell rate determines the maximum possible bandwidth. Typical applications may include TCP/IP and other LAN-based traffic.
UBR refers to Unspecified Bit Rate is used for connections that transport variable bit rate traffic which does not rely on any time synchronization between end systems. Unlike ABR, flow control mechanisms are not used to dynamically change the available bandwidth that is available to the user. UBR is used primarily for those types of traffic that are very tolerant of delay and cell loss. Typical applications include TCP/IP and store-and-forward traffic like file transfers and email across the Internet LAN and WAN environments.
As mentioned above, a DSLAM that incorporates QoS to prioritize the various types of incoming data would be desirable. With such QoS support, a DSLAM would be better equipped to handle all the different service requirements of the incoming data.
Accordingly, a need exists in the industry for a system or method that addresses problems raised by currently known DSLAMs and ATM switches.
A whole spectrum of inventive concepts is described herein, including the macro-level network architecture (and process), to the mid-level DSLAM/ATM switch itself, and the micro-level circuit implementations. In accordance with one embodiment of the present invention, a switching system called Intelligent Multiservice Access System (IMAS) provides DSLAM and ATM functionality in one unit. The major components in the IMAS chassis include line cards and chassis switch cards. With the line cards, the IMAS can be coupled to a plurality of loop technology ports (e.g., xDSL) on one side. With the chassis switch cards, the IMAS can be coupled to a plurality of WAN ports on the telecommunications backbone side for continued connectivity to an ATM network.
On the loop side, different variations of line cards are available so that each line card can support different numbers of ports. Thus, in one embodiment, the number of ports available in each line card ranges from eight to thirty-two. Also, the number of line cards that can be installed in an IMAS ranges from one to eighteen. These numbers are, of course, exemplary and the IMAS can support other numbers of ports and line cards, such as fifty ports per line card and twenty line cards per chassis.
In addition to the plity of ports on the loop side, each IMAS can also support a plurality of different loop technologies. In one embodiment, the IMAS is a carrier class digital subscriber line (DSL) access concentrator that can support multiple DSL transmission.types. Thus, a single IMAS supports ADSL, HDSL, IDSL, and SDSL, for example. Other combinations of xDSL transmission types are supported.
On the telecommunications backbone side, each chassis switch card is, in essence, a full function standalone ATM switch implemented as a single card in the IMAS chassis. Each chassis switch card provides ATM connectivity to the line cards in the chassis. An onboard CPU subsystem contains all functionality required to manage the chassis and perform all ATM processing functions. In one embodiment, two chassis switch cards are used per chassis, with two telecommunications backbone-side ports per chassis switch card. One of the ports in each chassis switch card is in hot standby (or active backup) mode for redundancy purposes in case of failure.
As for the internal data path architecture, the IMAS provides a high capacity non-blocking switch fabric. Depending on the configuration, the IMAS provides a switch fabric for supporting at least 5 Gbps bandwidth of traffic. With this design, oversubscription issues are minimized or eliminated altogether. To illustrate, one embodiment of the present invention is an IMAS with two chassis switch cards and eighteen line cards in the chassis. Each chassis switch card has two telecommunications backbone-side ports (one of which is in active backup mode) and eighteen line card-side ports (one for each of the eighteen line cards). Each line card has two chassis switch card-side ports (a port for each of the two chassis switch cards) and eight DSL-side ports. A representative topology is shown in FIG. 5.
The non-blocking feature will now be discussed for both the downstream and upstream directions. First, the downstream direction will be discussed. In accordance with one embodiment of the present invention, the telecommunications backbone side of the chassis switch cards provides data at a format and data rates that comply with OC3, STS3, T3, or E3. Accordingly, data at bandwidths of 155 Mbps can be provided to each of the chassis switch card""s telecommunications backbone-side ports. Each chassis switch card port, including the line card-side ports, supports 155 Mbps via cubit devices (i.e., Transwitch Cubit-Pro TXC-05802). Internally, the chassis switch card uses a shared bus at 640 Mbps. With this design, 155 Mbps data enters and leaves the chassis switch card uncongested in the downstream direction.
For the line cards, each line card-side chassis switch card port delivers 155 Mbps data. These ports are coupled to the two chassis switch card-side ports in each line card. With a standard UTOPIA interface, each chassis switch card-side port in the line card receives (and delivers) 155 Mbps data. A shared bus inside the line card supports 640 Mbps data. Using ADSL as an example, the framers and the ADSL modems support 8 Mbps downstream (telecommunications backbone side to DSL side) and 640 Kbps upstream (DSL side to telecommunications backbone side). In the downstream direction, 155 Mbps data is provided to the line cards and only the particular DSL technology employed limits the bandwidth.
In the upstream direction, assume that each line card having eight DSL ports are fully loaded. At 640 Kbps per ADSL line upstream, each line card receives an aggregate of 5.12 Mbps data (640 Kbpsxc3x978 ports per line card). For eighteen line cards, the aggregate bandwidth delivered to the chassis switch cards is 92.16 Mbps (5.12 Mbpsxc3x9718 line cards). Each line card-side port in the chassis switch card supports 155 Mbps and the shared bus supports 640 Mbps. The output telecommunications backbone side port also supports 155 Mbps data. Thus, the 92.16 Mbps upstream data from the line cards reaches and makes its way out of the chassis switch card uncongested. As illustrated by this example, this non-blocking feature practically minimizes or eliminates oversubscription for some IMAS configurations.
In accordance with another embodiment of the present invention, the IMAS enables support for the next generation of virtual connections. Regardless of whether the communications lines coupled to the inputs and outputs of the IMAS are based on SVC, PVC, or a combination of PVC and SVC, the IMAS can support SVCs for a more flexible, timely, efficient, and manageable connection. In the more typical configuration, the loop side of the IMAS is PVC-based because the modems do not support SVC signaling, and the telecommunications backbone side is capable of supporting SVC signaling even though existing DSLAMs do not employ SVC signaling logic. In another configuration, both the loop side and.the telecommunications backbone side are PVC-based. The IMAS supports this configuration.
With SVC support, the IMAS assists the ATM network in hand crafting an SVC-based connection almost immediately between end users when the originating end user wants to make a call to a destination end user, and tear down that virtual connection almost immediately when that call has completed. As described above, PVC call set up and termination were too time consuming, cumbersome, and inefficient. Needless to say, the IMAS supports SVC signaling for call establishment and termination if both the loop side and the telecommunications backbone side are SVC based.
For these non-signaling end systems, SVCs can still be supported using the proxy signaling aspect of the present invention. The proxy signaling aspect of the present invention uses a proxy signaling agent at the IMAS to control the virtual connection/circuit setup and termination of the non-signaling ATM end system. As mentioned above, proxy signaling calls are made on behalf of xDSL associated devices (e.g., ADSL modems) at the subscriber""s side because these devices currently do not support SVC signaling. The proxy signaling agent residing in the IMAS allows those PVC-supported calls directed to the OC3 uplink to be supported by SVC so that session-based virtual paths can be established as needed, without wasting valuable time for a PVC path to be established. As soon as the call (including the SVC signaling) is successful, a data connection is set up between the xDSL port at the IMAS in the central office and the OC3 uplink port. Similarly, an SVC call that had previously been established can be torn down via the same SVC signaling.
Proxy signaling calls are controlled by the proxy signaling group of an IMAS-specific MIB. As known to those skilled in the art, a MIB is a collection of managed objects that are software representations of actual physical parameters of a network device, such as the IMAS, which is used by SNMP agents to configure the device or get information from the device. The IMAS-specific MIB contains the Proxy Signaling Table, the ISP Table, and the Connect Info Table. These tables, which are shown in FIGS. 29, 30, 31, and 32, cross reference each other to make the desired SVC connections between subscribers. For example, one subscriber uses a device associated with an xDSL port (e.g., PC with modem at a small business) and the other subscriber is an ISP that provides a number of services, including Internet access. The establishment and termination of proxy signaling calls are controlled by the addition and deletion of information to these tables. The Proxy Signaling Table contains an entry for each xDSL port, VPI and VCI that is to be connected to an ISPxe2x80x94essentially, a call that comes in at one of the xDSL ports is destined for an ISP for which an SVC path must be set up. The ISP Table contains the ATM addresses of the ISPs that the xDSL connected devices (e.g., PC with modem) can connect with. The Connect Info Table contains information necessary to properly format the Setup message used to connect the SVC.
With the proxy signaling in place, the IMAS can use SVC signaling to dynamically negotiate with other nodes (e.g., ATM switches) in the telecommunications backbone for Quality of Service (QoS) and set up the connection. Without the SVC signaling, the system administrator would have to manually set up the path and connection that satisfy the desired QoS for that subscriber. Once negotiated, each node updates its own internal ports-to-virtual connections tables and sends back VCI numbers. When the IMAS receives a VCI number, it also updates its own internal tables so that a proper nodes-to-virtual connections mapping is provided. From this point on, the IMAS uses the negotiated VCI number and other relevant connection information for this particular call session. Once the call has completed, the proxy signaling process in the IMAS terminates the call via manipulation of these three tables.
How is the IMAS controlled and monitored? Generally, a sophisticated network management system (NMS) drives the software components of the IMAS for information collection and hardware configuration. Indeed, the NMS is also used to control and monitor other telecommunications equipment such as the various central office switches, DSLAMs, and ATM switches, besides the IMAS. Network administrators access the NMS and hence the IMAS via management consoles.
Representative tasks performed by the NMS include actively monitoring network resources for the purpose of device configuration, troubleshooting, detecting potential problems, improving performance, documentation, and reporting. The network management system performs other tasks including, but not limited to, autodiscovery of devices on the network; network topology mapping in the form of a graphic map that can be zoomed in or out; and the ability to schedule management tasks or jobs at specific times or dates. Other tasks include data backup, providing security, training users, and setting policies.
To enable the NMS to interface with a manufacturer""s equipment, such as the IMAS, the NMS includes some core NMS functionality and an IMAS-specific device manager in the NMS server. This device manager is a device driver-like piece of software that is unique to the manufacturer""s equipment. In one embodiment of the present invention, the device manager for the IMAS is called the IMAS device manager.
For data collection, data retrieval, and device configuration, the NMS uses the SNMP protocol and SNMP agents which are installed in various components throughout the IMAS. As known to those skilled in the art, SNMP is a simple request-response messaging protocol for setting parameters and getting information via SNMP agents to allow the NMS and the IMAS to communicate with each other. The core NMS functionality entity and the IMAS device manager in the NMS server can communicate with a master SNMP agent residing in the IMAS.
The master SNMP agent resides in the chassis of the IMAS. This master SNMP agent communicates with other sub-agents that are located in other software components of the IMAS. For example, when the NMS sends a request to obtain configuration information about line card 3, for example, the IMAS device manager delivers this request to the master SNMP agent in the IMAS. The master SNMP agent multiplexes this and other requests to the appropriate sub-agents for processing. In this example, the master SNMP agent delivers this line card 3 configuration information request to the sub-agent responsible for line card 3. This sub-agent then processes this request by delivering configuration information back to the master SNMP agent and then to the NMS server. The network administrator can produce reports based on the collected information that indicate the state of the network. SNMP agents can also generate alarms or traps that warn of problems or performance degradations on any part of the network.
These agents can only process those requests that are associated with a MIB. These MIBs are described in a MIB file which is associated with the core NMS functionality entity and the IMAS device manager to enable the NMS server to communicate with the IMAS.
The IMAS also supports end-to-end ATM over DSL. Because the IMAS is a fully compliant ATM switch that supports UNI 3.1, UNI 4.0, and PNNI 1.0 signaling, service providers can build end-to-end ATM networks over DSL from the subscriber""s premise through a carrier ATM backbone network. With fully integrated call admission control (CAC) and multiple queues implementing weighted fair queueing, the telecommunications service provider can deploy high speed DSL bandwidth to various types of subscribers and guarantee Quality of Service. The IMAS concentrates and switches traffic from multiple subscribers utilizing ATM as the layer 2 protocol over the DSL access network to transparently transport layer 3 protocols such as IP and IPX.
These and other embodiments are fully discussed and illustrated in the following sections of the patent specification.